I have concerns about proliferating menu options to accommodate preferences. The permutations could quickly become unmanageable. FWIW: I load the entire ./src into RGP Lua, and the number of menu options has exploded already.

Personally, I don't think spacing should even be an option. Finale itself has an automatic spacing option that may already take care of this. (Have you tested it?) Unfortunately, plugins cannot read this value, much as I have wanted to be able to through the years. FCGeneralPrefs seems never to have been expanded since about Finale 2000.

In my observations, there are two camps of Finale users regarding automatic spacing: people who want it all the time and people who never want it. (I'm in the latter camp.) It is unlikely they'd need to switch between behaviors. Therefore, I think it should remain a config parameter.

+1 to Robert's points. I currently have over 250 items in the menu bar. Any more becomes unwieldy—especially if it's for a preferences script that I'll only ever use once (if that).

I'd be open to having one script that can update all the preferences for all scripts, I'm not a fan of a different menu item for each script.

All comments noted. (Though to be fair, 23 of your menu items arise from your "4/4 meter" script!) Things like Layer Hide/Unhide used to be individual scripts - complementary function, so I'd maintain still useful as separate menu items.

Anyway, my last commit reverts to simple User .config file, with default behaviour "no music spacing".

(Though to be fair, 23 of your menu items arise from your "4/4 meter" script!)

Yeah… it works well when using Keyboard Maestro. However, using a script that I don't have a macro for is substantially slower.

(Though to be fair, 23 of your menu items arise from your "4/4 meter" script!)

This gets to the question of what should be a menu and what should be a config option and what should be a user setting. After thinking about this a second, here is a first draft of some ideas.

Menu Items

Menu items:

• Are functions that a user could reasonably be expected to use on a regular or semi-regular basis.
• Are functions that should be easily accessible to keyboard maestro and the like.
• Do not change.

The 23 menu items in "4/4" seem to be clearly in this category (though I blanched at the number of items when Nick originally proposed them.) Even if I personally don't use every one of them, I can imagine using them and I have already used more of them than I could list. Also, they correspond to a menu in Finale, so they are literally making a Finale menu available to keyboard maestro that was not available to it before.

Configuration Items

Configuration items:

• Embody behavior that reflects the preferences of the user.
• Are rarely expected to change for a given user.
• Are set or changed only by users comfortable with editing text files (at least currently).

I see the spacing option in this PR as in that category (as I commented above). Most users either want or do not want automatic spacing, and that preference almost never changes. If Finale provided access to the automatic spacing program option, we could dispense with the script's configuration option altogether and base the script's behavior on Finale's option. But alas, that road is closed to us.

User settings

User settings:

• Allow scripts to persist data across calls, such as the last data entered into a dialog box.
• May change frequently.
• Are written and read by the script itself.
• Can replace configuration items.

(If we can agree on these lists, I'll add them to the comments in configuration.lua.)

Having an agreed set of criteria will save a lot of discussion time down the track, and this is an excellent set of orthogonal formulae to start with.

A few suggestions ...
Menu Items:

1. "at least" is redundant
2. "that should" not "the should"

Configuration Items:
2) Are expected to remain consistent for each user

User Settings:
4) .. if there is a clear distinction between configurations and settings then I don't think settings should be able to "replace" configurations.

I addressed the typos in the original comment.

I see user settings as being an "upgrade" or superset of configuration options. If a script has user settings, it has no need for configuration options. Basically, configuration options are the legacy and user settings are the future. But it's a little more complicated than that because a script may want to have some configuration options without going to the trouble of creating a user interface to edit them.

Here is a case in point: all the various nudger scripts. Currently the nudge amount is either a configuration option or a hard-coded value that could become a configuration option. It has occurred to me that I could add an optional dialog to them, accessed by invoking with Option/Shift (see #246), to allow the user to edit the nudge amount. This converts a configuration option to a user setting.

I could get behind this approach.

Not to be picky, but aren't the most salient element of UserSettings that:

1. they are chosen by the user within the script
2. the same user is likely to make different choices depending on the context (unlike configs)

Furthermore that they should (could?) be realised using RetainLuaState rather than saved to file unless there are many parameters, or it's important to retain choices between Finale restarts?

From my perspective, the most salient point of user settings is that the script must provide a UI (or other means if you can think of one) to modify them. Once you are providing a UI, does it really matter how often one of the fields changes?

RetainLuaState is fine as far as it goes, but retaining user choices across Finale calls is even better. I notice that in your other scripts you dropped RetainLuaState in favor of user settings. That's an inclination I support. But it's also good to have a variety of tools at our disposal. RetainLuaState is still an excellent tool for saving the result of an expensive calculation. (For example, the class index that the RGP Lua Class Browser creates.) But with user settings it is perhaps less useful than user settings for persisting user choices (including modeless window position).

PS: just noting that my final commit d833a65 (not yet merged) addressed your initial concerns.

I just had one tiny comment left: the blank line in the Notes should be before the first triple-tick mark not before the 2nd triple-tick mark (as it is now).

Of course. Sorry - I misunderstood.